Skip to content

sv2-tp: exit on bitcoin core IPC disconnect#100

Open
enirox001 wants to merge 2 commits intostratum-mining:masterfrom
enirox001:05-26-clean-exit-disconnect
Open

sv2-tp: exit on bitcoin core IPC disconnect#100
enirox001 wants to merge 2 commits intostratum-mining:masterfrom
enirox001:05-26-clean-exit-disconnect

Conversation

@enirox001
Copy link
Copy Markdown

This fixes sv2-tp remaining alive but unusable after losing its Bitcoin Core IPC backend.

Catch ipc::Exception from template provider mining calls, mark the backend as disconnected, interrupt local threads, and let main exit with failure when backend loss is detected.

This takes the simpler shutdown path instead of trying to reconnect in-process. It avoids introducing backend swapping or reconnect state into the current sv2-tp lifecycle, and lets an external supervisor handle restart.

Before this change, stopping Bitcoin Core left sv2-tp running with open sockets but no ability to serve templates. After this change, sv2-tp shuts down and exits nonzero on backend disconnect, while preserving EXIT_SUCCESS for normal operator shutdown.

Tested manually on regtest by:

  • starting Bitcoin Core with IPC enabled
  • starting sv2-tp and connecting an SRI pool
  • stopping Bitcoin Core
  • verifying that sv2-tp exits after detecting the IPC disconnect

Catch IPC exceptions from mining calls in the template provider and
mark the backend as disconnected when they occur.

This lets sv2-tp distinguish a fatal backend disconnect from a
normal shutdown and unwind its worker threads without making further
IPC calls on a dead connection.
Exit sv2-tp with failure when the template provider reports that its
Bitcoin Core IPC backend has disconnected.

This makes backend loss visible to process supervisors while
preserving EXIT_SUCCESS for operator-initiated shutdowns.
@enirox001 enirox001 changed the title sv2-tp: exit on Bitcoin Core IPC disconnect sv2-tp: exit on bitcoin core IPC disconnect May 1, 2026
@Sjors
Copy link
Copy Markdown
Collaborator

Sjors commented May 1, 2026

Why not just try to reconnect with exponential backoff?

@enirox001
Copy link
Copy Markdown
Author

Why not just try to reconnect with exponential backoff?

Reconnecting with exponential backoff is the preferable behavior. I am working on this approach

This PR was opened to make the smaller exit-on-disconnect approach concrete in case that behavior was considered acceptable. It is a narrower change and avoids introducing reconnect and backend-lifecycle management into the current sv2-tp design.

This can be treated as a reference point for the simpler shutdown path rather than the proposed final direction.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants